Date: Wed, 4 May 94 04:30:14 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #137 To: Ham-Digital Ham-Digital Digest Wed, 4 May 94 Volume 94 : Issue 137 Today's Topics: Idea, 10-10 members.... Integrate HF w/WAN NET/ROM NRS specification New FCC rules on forwarding PacketRadio forLinux with Baycom ?? (2 msgs) Packet radio FTP sites still looking for project ideas (2 msgs) unsubscribe Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 3 May 1994 19:10:20 GMT From: darwin.sura.net!rsg1.er.usgs.gov!news.cs.indiana.edu!noose.ecn.purdue.edu!constellation.ecn.purdue.edu!wb9omc@seismo.css.gov Subject: Idea, 10-10 members.... To: ham-digital@ucsd.edu I'd like to gauge the interest among members of 10-10 International who are on the Internet for a group, possibly called: rec.radio.amateur.1010 The purpose of the group would be multiple: 1) to help disseminate information of general interest to 10-10 members who have access to Internet. 2) to help 10-10 members set up skeds, nets and other communications events. 3) to help develop interest in not only 10-10 International but to maintain interest in 10 meters in *spite* of the current lull in the band. 4) to help develop computer operating aids for 10-10 contests and paperchasing. 5) to serve as one focal point for 10-10 members to discuss the organization, contest rules, awards rules, etc. 6) other future purposes realted to Amateur Radio and 10-10. *********** I think that emailing me would probably be preferred to clogging up a number of newsgroups with "me too!" kinds of mail. If you are interested or have a *brief* thought on the subject, please email: wb9omc@harbor.ecn.purdue.edu flames and/or mail bombs will be ignored, deleted, /dev/null'ed, etc. :-) If interest seems positive enough, I will make some contacts with the officers of 10-10 to find out in what ways, if at all, they would like to make contact and maintain contact with such a newsgroup. 73 Duane, WB9OMC ------------------------------ Date: Tue, 3 May 1994 13:37:51 GMT From: ihnp4.ucsd.edu!sdd.hp.com!nigel.msen.com!zib-berlin.de!math.fu-berlin.de!news@network.ucsd.edu Subject: Integrate HF w/WAN To: ham-digital@ucsd.edu In article <7c5PLc6w165w@voxbox.norden1.com>, jgrubs@voxbox.norden1.com (Jim Grubs, W8GRT) says: > >Correct me if I'm wrong, but isn't HF illegal under ITU >Conventions for intranational land mobile use? Don't know, is it? This could be a problem! I'll talk with our frequency coordinator and see what he can tell me. Would it be in an FCC reg, the Communications Acts of 19xx, or some other reference? Kevin der Kinderen mtimpn@baileys-emh2.army.mil 703-756-1971 Opinions voiced are my own, not my employer's. ------------------------------ Date: Tue, 3 May 1994 08:37:18 +0000 From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net!pipex!demon!athnet.ath.forthnet.gr!sv1xv@network.ucsd.edu Subject: NET/ROM NRS specification To: ham-digital@ucsd.edu I need the specification of NRS (Net/Rom transmission over serial lines). Is it available anywhere? Thanks, Costas +---------------------------------------------------------------+ | Costas Krallis - SV1XV - Athens Greece (LOC: KM18UA) | | Packet Radio: sv1xv@sv1uy.ath.grc.eu | | Internet: sv1xv@athnet.ath.forthnet.gr | | S-Mail: P.O.Box 3066, GR-10210 Athens, GREECE | | PGP Public Key 0x9E2905 available from all public keyservers. | +---------------------------------------------------------------+ ------------------------------ Date: 3 May 94 15:37:28 GMT From: news-mail-gateway@ucsd.edu Subject: New FCC rules on forwarding To: ham-digital@ucsd.edu The FCC has finally released the text of the Part 97 changes relative to message forwarding. According to an article in the April 26 ARRL Letter, the new rules are: 97.3 Definitions. (7) Auxiliary stations. An amateur station, other than in a message forwarding system, that is transmitting communications point-to-point within a system of cooperating amateur stations. (28) Message forwarding system. A group of amateur stations participating in a voluntary, cooperative, interactive arrangement where communications are sent from the control operator of an originating station to the control operator of one or more destination stations by one or more forwarding stations. (36) Repeater. An amateur station that simultaneously retransmits the transmission of another amateur station on a different channel or channels. 97.109 Station control. (e) No station may be automatically controlled while transmitting third party communications, except a station participating as a forwarding station in a message forwarding system. 97.205 Repeater station. (g) The control operator of a repeater that retransmits inadvertently communications that violate the rules in this Part is not accountable for the violative communications. 97.219 Message forwarding system. [Section 97.216 is redesignated Section 97.217] (a) Any amateur station may participate in a message forwarding system, subject to the privileges of the class of operator license held. (b) For stations participating in a message forwarding sytem, the control operator of the station originating a message is primarily accountable for any violation of the rules in this Part contained in the message. (c) Except as noted in paragraph (d) of this section, for stations participating in a message forwarding system, the control operators of forwarding stations that retransmit inadvertently communications that violate the rules in this Part are not accountable for the violative communications. They are, however, responsible for discontinuing such communications once they become aware of their presence. (d) For stations participating in a mesage forwarding system, the control operator of the first forwarding station must: (1) Authenticate the identity of the station from which it accepts communications on behalf of the system: or (2) Accept accountablility for any violation of the rules in this Part contained in messages it retransmits to the system. These rules will take effect June 1, 1994. ------------------ Bob Nielsen, W6SWE Internet: w6swe@tapr.org Tucson, AZ AMPRnet: w6swe@w6swe.ampr.org [44.124.12.16] AX.25: w6swe@wb7tls.az.usa.na ------------------------------ Date: 3 May 1994 21:04:34 GMT From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net!torn!hermes.acs.ryerson.ca!ee.ryerson.ca!jeff@network.ucsd.edu Subject: PacketRadio forLinux with Baycom ?? To: ham-digital@ucsd.edu irene burlingame (ipb@unlinfo.unl.edu) wrote: : Is there anybody out there hwo has experience with setting up a Linux : Packetradio server using a Bycom modem? i need info desperately! Unfortunately, Linux will never be able to support Baycomm. The Baycomm modem requires that the processor be 100% devoted to the modem while packets are coming in and out, and that's just not possible under a multitasking OS. Even if you could do it, it's really not desireable, it would bring the whole machine to a halt! 73 de Jeff / VE3DJF Jeff@EE.Ryerson.Ca VE3DJF@bbs.VE3RPI.ampr.org ------------------------------ Date: 4 May 94 10:01:55 GMT From: agate!howland.reston.ans.net!EU.net!CERN.ch!dxcern!jalocha@ucbvax.berkeley.edu Subject: PacketRadio forLinux with Baycom ?? To: ham-digital@ucsd.edu In <2q6e92$kbk@hermes.acs.ryerson.ca> jeff@ee.ryerson.ca (Donald Jeff Dionne) writes: >Unfortunately, Linux will never be able to support Baycomm. The Baycomm >modem requires that the processor be 100% devoted to the modem while >packets are coming in and out, and that's just not possible under >a multitasking OS. Even if you could do it, it's really not desireable, >it would bring the whole machine to a halt! Not 100% true :-) For receiving packets the processor only reacts to modem output transitions and it is done via an interrupt. The key point is that the CPU has to measure the time when the interrupt occured with a precision better than the time taken by a single bit (3.3 ms for 300 bps, 0.833 ms for 1200 bps). A precision of about 0.1 ms is good enough for 1200 bps. The trouble comes if the processor runs with interrupts disabled for the time which is longer than the precision needed... I can not say whether the LINUX system does so. The approach I described above is applied in the BAYCOM program and the AX.25 driver for the NOS written by me. The TFPCX driver takes a different approach by speeding up the system timer and sampling the modem's output at three times the bit rate frequency. Bottom line: if the LINUX operating system doesn't "blind" the CPU to interrupts for longer than about 0.1 ms one could (in principle) write a driver for the BAYCOM modem running at 1200 bps. Pawel, SP9VRC ------------------------------ Date: Tue, 03 May 94 18:14:52 GMT From: koriel!cs.utexas.edu!howland.reston.ans.net!EU.net!uknet!ukc!raven.ukc.ac.uk!mrb3@ames.arpa Subject: Packet radio FTP sites To: ham-digital@ucsd.edu HI all, I was wondering if anyone has a list of the best ftp sites around that contain amateur radio / packet related programs. Many thanks Matthew Packet G7KSG@GB7ZAA -- __ __ _ _ | \/ |__ _| |_| |_ | |\/| / _` | _| _| |_| |_\__,_|\__|\__|......... ------------------------------ Date: 3 May 94 23:39:56 GMT From: dog.ee.lbl.gov!ihnp4.ucsd.edu!sdd.hp.com!saimiri.primate.wisc.edu!news.doit.wisc.edu!kolstad@ucbvax.berkeley.edu Subject: still looking for project ideas To: ham-digital@ucsd.edu In article <1994May3.152521.1@exodus.valpo.edu> acc_mwb@exodus.valpo.edu (Mike Barton) writes: > >We'd like it to be in the are of electronics. Audio applications, signal >processing, waveform modification, signal generation, filtering, etc. I don't >know what else... so many different things, we hardly know where to start. I'd be impressed if you got a 1Gb/s fiber optic link going. :-) I take an opto-electronics course once that had a student made fiber optics demonstrator box that cranked out a whole 100 kbps!! Oooh, wow! (Sorry... most of the labs here at the U of W have really crappy equipment... there's a reason they call this a "Research University.") ---Joel Kolstad ------------------------------ Date: 3 May 94 15:24:07 CDT From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!math.ohio-state.edu!sol.ctr.columbia.edu!usenet.ucs.indiana.edu!vunews.valpo.edu!exodus.valpo.edu!acc_mwb@network.ucsd.edu Subject: still looking for project ideas To: ham-digital@ucsd.edu I am currently finishing my junior year in electrical engineering. Next year, I will be working on a "senior project" with at least one other student. Taking a look ahead, we're trying to figure out some options for projects that we could do. We'd like it to be in the are of electronics. Audio applications, signal processing, waveform modification, signal generation, filtering, etc. I don't know what else... so many different things, we hardly know where to start. Other options that we'd like to consider are those in the communication electronics area. We'll be having communic. theory and electronics classes next year, so right now, we don't have much to go on in that area. I am an amateur radio operator. Something dealing with that would be really great! Other areas of interest that might generate a good project would me some digital / electronics combination, applications dealing w/ transistors as switching (not in a power situation, but rather small things). This project lasts two semesters. In the fall we finalize our project. Write up some designs, present the project, make a "project request" or something like that. Then, by Dec., have it ready to put together. Starting in Jan., we build a prototype, fix it, get it to work (ie. re-design and re-design and..). Finally, we'll end the semester by writing final reports, documentation and doing more presentations. We'd like any ideas for projects that you think would be interesting, obtainable, and fit the idea of this "senior project." ___PLEASE____ if you've got any ideas, send some email to me. Just give us a couple of ideas that you might have. I'll post a summery to the list if I get some responses. -- ___ Mike (o o) ---------m-^-m--------------------------------------------------------------- ------------------------------ Date: 3 May 94 22:55:17 GMT From: news-mail-gateway@ucsd.edu Subject: unsubscribe To: ham-digital@ucsd.edu unsubscribe help ------------------------------ Date: Tue, 3 May 1994 12:41:27 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!library.ucla.edu!csulb.edu!csus.edu!netcom.com!rogjd@network.ucsd.edu To: ham-digital@ucsd.edu References <1994Apr26.000004.23739@news.csuohio.edu>, <1994Apr26.151137.6512@midway.uchicago.edu>, · Subject : Re: A soft spot in the Pactor protocol??? Anyone know if GTOR has a reconnect protocol? Or is it similar to Pactor in this regards? -- rogjd@netcom.com Glendale, CA AB6WR ------------------------------ End of Ham-Digital Digest V94 #137 ******************************